One widely accepted computer architecture, developed specifically to accommodate the “distributed computing” environment, is the client-server model. In its purest form, a client-server system consists of a central server (sometimes called the host), which is a very powerful computer (or cluster of computers that behaves as a single computer) that services the requests of a large number of smaller computers, or clients, that connect to it. The client computers never communicate with one another, instead exchanging data only with the server, which thereby acts as a clearinghouse for client requests and inter-client communications. A server, therefore, may be a large mainframe or minicomputer cluster, while the clients may be simple personal computers.
Although they need not be powerful, it is nonetheless important that clients possess a basic level of on-board processing capability; unlike older timeshare systems, which utilized “dumb” terminals that were essentially driven by the central machine, the client-server model requires that each client be capable of independent computational operation. In this way, the central server need only accept and deliver messages to the clients, which process them for output to the user. This approach limits the processing burden on the server and facilitates faster, readily customized responses by the clients.
An exemplary client-server configuration is illustrated in FIG. 1. A central server 10 communicates with a series of client computers 121, 122, 123, 124 . . . 12n over a coextensive series of physical connections 141, 142, 143, 144, . . . 14 n. The terms “server” and “host” are herein used interchangeably to denote a central facility consisting of a single computer or group of computers that behave as a single unit with respect to the clients. In order to ensure proper routing of messages between the server and the intended client, the messages are first broken up into data packets, each of which receives a destination address according to a consistent protocol, and which are reassembled upon receipt by the target computer. A commonly accepted set of protocols for this purpose are the Internet Protocol, or IP, which dictates routing information and the Transmission Control Protocol, or TCP, according to which messages are actually broken up into IP packets for transmission for subsequent collection and reassembly. TCP/IP connections are quite commonly employed to move data across telephone lines, and have been adopted not only by online services but throughout the worldwide, integrated network communication web known as the Internet.
The server executes a variety of applications in response to requests issued by clients. Within a typical client server architecture, however, most of these requests are for retrieval of information stored on one of the server's databases. The application programs executed by the server, therefore, by and large relate to data management and transfer. In this sense, the term “application” denotes a body of functionality for obtaining, processing and/or presenting data to a user. For example, electronic mail (e-mail) facilities allow the user to send and receive memo-type communications; document browsers display hierarchically organized collections of document titles, any of which can be obtained by a user simply by “clicking” on a title with a position-sensing mouse device or otherwise designating the document. Applications can be “active,” operating only when affirmatively engaged by a user, or maintain a “background” task mode, which operates even when the application is not active.
Related to client server architectures, object-oriented programming divides monolithic applications into objects. In an object-oriented system, each object is associated with a unique identifier, and may or may not be represented by contiguously stored electronic data. Indeed, an item need not even reside on a single database; the server's database management software assembles an item (e.g., an article containing related text and image data) from its constituent components and transfers the item so that the user receives it as a single unit.
It is also possible to “encapsulate” procedures within the objects themselves, thereby reducing the programming burden on applications designed to interact with objects; those applications need not “know” the details of object management and display, since each object carries its own structure and effectively orchestrates its own behavior.
Objects also possess the property of “heritability,” whereby properties or attributes of hierarchically superior objects are automatically inherited by hierarchically inferior objects. Heritability is managed by organizing the objects into classes, each of which represents the template for a set of similar (in the sense of sharing structure and behavior) objects. Each object is an instance of some class. Thus, objects in a subclass automatically acquire the procedures associated with hierarchically superior objects.
Hierarchical relationships among objects are not limited to inheritance and class. In addition, objects can be related to one another based on a hierarchical ranking, with higher-tier “parent” objects having pointers to lower-tier “children” objects. As a result, higher-tier objects behave as if they “contain” hierarchically related, lower-tier objects.
Objects can also be linked to one another. A linked object, while not contained in the linking object in the manner of a lower-tier object, is nonetheless referenced in the linking object. The procedures associated with the linking object determine the significance of the reference and its effect.
Management of object classes, attributes, encapsulated procedures and inter-object linkages typically occurs through an object-oriented database (“OODB”) system, design and implementation of which are well-known in the art.
With typical client server architectures, an application may be divided between the client and the server, using object-oriented programs and each processor performing some part of an overall task. This separation may be used to optimize efficiency of the application, or to off-load processing to the client when the server resources are better applied to other tasks. While effective in typical client server architectures, this division of tasks between different processor resources becomes difficult when multiple client server systems are inter-connected. The interconnections may be dynamic and therefore not easily anticipated when the application is built. Further, different systems may operate with different operating systems, making resource sharing and cross-operating system object interaction difficult.
To accommodate the widely distributed nature of future computing, facilitated by wideband high-speed data interconnections, standards-based distributed architectures have evolved. One emerging standard for distributed objects is Distributed Component Object Model (DCOM). DCOM allows subdivision of monolithic client server applications into self-managing components or objects that interact with each other and freely move throughout a network and across operating system boundaries. By assembling these distributed components, in a dynamic manner, application developers quickly address specialized user needs without the requirement for building a monolithic application. With suitable standards, distributed objects become plug-and-play software components able to manage complex systems.
However, the dynamic behavior of DCOM introduces new challenges for building reliable distributed applications. Due to its desktop document processing origin, many DCOM application programming interfaces (APIs) are not structured and presented in an intuitive way for building distributed client/server applications. As a result, although the design of the DCOM architecture is quite extensible (that is, reasonable defaults are provided for common cases, but can be overwritten through flexible programming hooks), it often involves non-intuitive programming hacks to provide the functionality required in a client/server environment.
Before DCOM can be used to build mission-critical applications, there is a need to provide greater fault-tolerance and address reliability and availability issues for distributed objects.